
================================================================================
Things that need validation by the compiler
================================================================================
Many of these are probably already covered, but being paranoid.
Make a list of things as I think of them.
Keep them here in case I forget and re-think of them.

Mark these as follows:
    X = Yes, confirmed that the compiler covers this
    ! = No! Confirmed that the compiler does not check this, and should.
    ? = TBD

--------------------------------------------------------------------------------

X resetsignal width
    reset signals shall have width of 1

X Field has no knowable value
    - does not implement storage
    - hw is not writable
    - sw is readable
    - No reset value specified

    --> emit a warning?

X References to a component or component property must use unambiguous array indexing
    For example, if "array_o_regs" is an array...
    The following is illegal:
        my_reg.my_field->next = array_o_regs.thing
        my_reg.my_field->next = array_o_regs.thing->anded
    This is ok:
        my_reg.my_field->next = array_o_regs[2].thing
        my_reg.my_field->next = array_o_regs[2].thing->anded

    NEVERMIND - compiler does not allow indefinite array references at all!
    References are guaranteed to be unambiguous:
        "Incompatible number of index dimensions after 'CTRL'. Expected 1, found 0."

X Clause 10.6.1-f (wide registers cannot have access side-effects)

X multiple field_reset in the same hierarchy
    there can only be one signal declared with field_reset
    in a given hierarchy

X multiple cpuif_reset in the same hierarchy
    there can only be one signal declared with cpuif_reset
    in a given hierarchy

X Mutually-exclusive property checking
    --> Yes. compiler now auto-clears mutex partners on assign, so it is
        implicitly handled

X incrwidth/incrvalue & decrvalue/decrwidth
    these pairs are mutually exclusive.
    Make sure they are not both set after elaboration
    Compiler checks for mutex within the same scope, but
    i dont think I check for mutexes post-elaborate

    ... or, make these properties clear each-other on assignment

X Illegal property references:
    - reference any of the counter property references to something that isn't a counter
        decrsaturate / incrsaturate / saturate
        overflow / underflow
    - reference hwclr or hwset, but the owner node has them set to False
        means that the actual inferred signal doesnt exist!
    - reference swwe/swwel or we/wel, but the owner node has them, AND their complement set to False
        means that the actual inferred signal doesnt exist!
    - only valid to reference if owner has this prop set
        enable/mask
        haltenable/haltmask
        hwenable
        hwmask
        decr/incr, decr../incrthreshold/..value
    - others references that may not always make sense:
        intr/halt - target must contain interrupt/halt fields
        next
            is this ever illegal?

X If a node ispresent=true, and any of its properties are a reference,
    then those references' ispresent shall also be true
    This is an explicit clause in the spec: 5.3.1-i

X Flag illegal sw actions if not readable/writable
    The following combinations dont get flagged currently:
        sw=w; rclr;
        sw=w; rset;
        sw=r; woset;
        sw=r; woclr;
    their counterparts do get flagged. such as:
        sw=w; onread=rclr;

X Signals marked as field_reset or cpuif_reset need to have activehigh/activelow
  specified. (8.2.1-d states that activehigh/low does not have an implied default state if unset!)
  Also applies to signals referenced by resetsignal

X incrvalue/decrvalue needs to be the same or narrower than counter itself

X field shall be hw writable if "next" is assigned.

X sticky=true + "(posedge|negedge|bothedge) intr"
    Edge-sensitivty doesnt make sense for full-field stickiness

X we/wel + implied or explicit "sticky"/"stickybit"
    we/wel modifier doesn't make sense here.

X sticky/stickybit shall be hw writable

X Illegal to use enable/mask/haltenable/haltmask on non-intr fields

X incrwidth/decrwidth must be between 1 and the width of the counter

X counter field that saturates should not set overflow
    counter; incrsaturate; overflow;
    counter; decrsaturate; underflow;

    Flag this as an error on the overflow/underflow property.
    overflow/underflow property is meaningless since it can never happen.

    Same goes to prop references to overflow/underflow

! hwclr/hwset/we/wel probably shouldn't be able to reference itself
    y->hwclr = y;
    y->we = y;
    ... it works, but should it be allowed? Seems like user-error

================================================================================
Things that need validation by this exporter
================================================================================
List of stuff in case I forget.
    X = Yes! I already implemented this.
    ! = No! exporter does not enforce this yet

--------------------------------------------------------------------------------

X Contents of target are all internal. No external regs

X Does not contain any mem components

X Warn/error on any signal with cpuif_reset set, that is not in the top-level
    addrmap. At the very least, warn that it will be ignored


X "bridge" addrmap not supported
    export shall refuse to process an addrmap marked as a "bridge"
    Only need to check top-level. Compiler will enforce that child nodes arent bridges

X regwidth/accesswidth is sane
    X accesswidth == regwidth
        Enforce this for now. Dont feel like supporting fancy modes yet
        X regwidth < accesswidth
            This is illegal and is enforced by the compiler.
        X regwidth > accesswidth
            Need to extend address decode strobes to have multiple bits
            this is where looking at endianness matters to determine field placement
            Dont feel like supporting this yet
    X constant regwidth?
        For now, probably limit to only allow the same regwidth everywhere?


X Do not allow unaligned addresses
    All offsets & strides shall be a multiple of the regwidth used

    X each reg needs to be aligned to its width
    X each regfile/addrmap/stride shall be aligned to the largest regwidth it encloses

X Error if a property is a reference to something that is external, or enclosed
  in an external component.
  Limit this check to child nodes inside the export hierarchy

! async data signals
    Only supporting async signals if they are exclusively used in resets.
    Anything else declared as "async" shall emit a warning that it is ignored
    I have zero interest in implementing resynchronizers

! Error if a property references a non-signal component, or property reference from
    outside the export hierarchy

! Add warning for sticky race condition
    stickybit and other similar situations generally should use hw precedence.
    Emit a warning as appropriate
    Or should this be a compiler warning??
